Hello,
> I don't see how using a GUID can solve the finder problem. Won't you get
> object slicing (an A entity bean instantiated around a B bean's
> data) if you
> use an A home finder method that happens to match a B bean? How
> does a GUID
> resolve this?
Yes, you are right. My goal was to have a shared set of ID, possibly in
different tables (one for each class). If you want to have them in the same
table, you have either to choose an implicit solution like yours (the type
is determined by the range) or an explicit solution by adding a column used
as a discriminant between classes.
> And regarding needing to fix the finder methods as you add new
> subclasses...
> Either:
> a) you get the slicing problem that I listed above, in which case my
> solution eliminates the slicing problem, and there is no way to get the
...
> work, but it would involve moving your 'real' finder methods from
> the home
> class to a session bean (since the home class is generated).
OK, I see your proposal. But are you sure that all your classes beans will
be able to correctly register to their mother class? i.e.
- they will be able to do it on time (before any request happen to the
mother),
- nothing prevent the EJB server (I guess), to load each bean in a separate
JVM => your mother class will never receive subscription from its children
classes
- ...
I do not have enough knowledge in JBoss internals (and in other servers as a
solution is really interesting if it is portable) to be sure of the risks I
mentionned above.
Anyway, by using some kind of service (registered in JMX) that would take
care of handing the knowledge of your inheritance structure, your solution
should work I guess.
Interesting anyway...
Cheers,
Sacha
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
