Christian Ruediger wrote:
> Now for the idea, how this should work:
> The common set of data is managed by an Entitybean. Each of
> the devices is represented by one such Entitybean. In
> addition for each device exists one spezialized data set in
> an Enitybean. Of course for each devicetype (=set of
> specialized data) there must exist an Entitybean representation.
I have something a little similar in our Identity (user and profile)
system. Users have Profiles (one per BusinessUnit to which they belong)
with common fields (screen name, referral, etc). Beyond that, each BU
may want to track different preferences for each user (favorite genre
for one BU, favorite soap opera for another, etc). Instead of modeling
these extra fields in the schema which would make it hard to maintain
and more difficult to extend later, I created a separate table of
property values.
BusinessUnit -- 1:N --> BuPropertyDefinition
^ ^
| |
N:1 N:1
| |
Profile -- 1:N --> BuPropertyValue
Each BU defines its set of properties (the definitions), and then each
Profile has a collection of property values, one for each property
definition for the Profile's BU. Thus, all of the properties are simply
data elements and can be extended at runtime without rebuilding the
system.
At one point I created a subclass of Profile for each BU and added
specific accessors for the properties, but this merely complicated the
design and deployment process. Since the values were mostly being used
by Struts forms, it was just as easy to access the property with a
String key, so I dropped that part. If you need expressive programmatic
access to the attributes, you may still want that part.
If you're using your EJBs truly as a data-access layer, then you can
hide all of this behind your DAO interfaces. In any case, you may be too
far into it, or simply feel your solution is optimal (as it may be; this
is just what I did), so let's go with what you've got.
> Now again back to my problem:
> While coding this scenario by hand is not a problem, I get
> problems when trying to generate the necessary code. Xdoclet
> generates the ejb-jar.xml correctly. As each
> specialized-device-EnityBean inherits the common
> device-Entitybean, Xdoclet correctly enters the signatures of
> all methods including findermethods in the Home Interface. So
> far for the xml-file. I can not inherit the common-devices
> Homeinterface, because createmethods would collide.
This is merely a problem with inheritance in EJB. I haven't delved into
it too deeply, but it seems you can inherit the home interfaces because
of this (different return types from ejbCreate). To get around this, I
believe you can specify that your subclass home interfaces *do not*
extend the base class ones, but then you have problems with the finders.
> But as
> the signatures of the finder methods are in the deployment
> descriptor, they should also be in the
> Homeinterface. That is wherer XDoclet fails. The finders of
> the superclass are automatically added to the deployment
> section of its heirs, but the finders are not inserted into
> the generated source code.
Have you searched the archives? I think I saw a fairly detailed message
about inheritance about a year ago, when I first started using XDoclet.
The main problem as I see it is that to load an entity bean the
container chooses a bean instance from the pool, assigns it the PK of
the bean to load, and then calls ejbLoad(). Now, ejbLoad() will read in
an attribute that you would normally use to determine which specific
subclass the bean should be. But the container has already chosen a bean
instance -- most likely the base class. I don't see a way for it to
shuffle all this to a new bean instance of the correct type. Well, I see
that it could, but I doubt it happens.
Given that, it seems that your code must always explicitly say which
type of bean subclass to load. At that point, you've pretty much lost
polymorphism. This will result in a lot of code bloat to deal with each
new subclass. At best, you may be able to do it without extending home
interfaces, meaning you have to recode all the base create methods and
finders for each subclass.
David Harkness
Sr. Software Engineer
Sony Pictures Digital Networks
(310) 482-4756
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
