Dynamic top class resolution?

[ad...@netspace.net.au]

Hi All,

The following query refers to the method getTopLevelClass(Class clazz) beginning
line 144 in the final class org.apache.ojb.broker.metadata.DescriptorRepository
using OJB 1.0.1.

I have descriptor repositories that use interfaces rather than direct classes. 
I don't want to have to declare extents for the implementing classes to be
stored, I determine which class to instantiate at runtime using a custom row
reader.  The only information I'm interested in storing is the contract
information specified by the interface.

For example:

  ------------------
  | <<interface>>  |
  |     User       |
  |----------------|
  |----------------|
  ------------------
         /\
        /__\
          |
          
          |

          |

          |
   -----------------
   |    UserVO     |
   |---------------|
   |---------------|
   -----------------


Where the user is declared.

        <class-descriptor
                class="com.interlinkj.ac.User"
                table="USERS"
        row-reader="com.interlinkj.db.UserRowReader">
                <field-descriptor
                        name="id"
                        column="id"
                        jdbc-type="INTEGER"
                        primarykey="true"
                        autoincrement="true"/>
                <field-descriptor
                        name="firstName"
                        column="firstname"
                        jdbc-type="VARCHAR"
            nullable="false"/>
                <field-descriptor
                        name="lastName"
                        column="lastname"
                        jdbc-type="VARCHAR"
            nullable="false"/>
                <field-descriptor
                        name="userName"
                        column="username"
                        jdbc-type="VARCHAR"
            nullable="false"/>
                <field-descriptor
                        name="passwordHash"
                        column="credentials"
                        jdbc-type="VARCHAR"
            nullable="false"/>
                <collection-descriptor
                name="groups"
                element-class-ref="com.interlinkj.ac.Group"
                indirection-table="USER_GROUP_LINK"
                auto-delete="link"
                auto-update="object"
            auto-retrieve="true"
            orderby="id"
            sort="ASC"
        >
         <fk-pointing-to-this-class column="user_id"/>
         <fk-pointing-to-element-class column="group_id"/>
        </collection-descriptor>
        </class-descriptor>


Now I won't go into the 'group' mapping as it took far to long to draw the UML
diagram for User :).

The user row reader simply instantiates UserVO and copies the values in, returns
the user.

You may be thinking this is kind of a strange thing to do, however I won't know
what 'user' implementation is being used until runtime.  This is a simple
example, I have much more complex examples in our application of wanting to
store interface based information based on configurable subclasses.

Now this saves without a problem, however when loading and resolving the m:n
relationship, the Identity class is used (the constructor that takes an Object
and PersistenceBroker)...which, if you follow the calls back, using the
getTopLevelClass on the DescriptorRepository to set the top level class. 
Because the implementing class isn't declared as an extent of the interface, the
top level class ends up being set to the implementing class.  It's fairly simple
to add some code to use common-lang ClassUtils to check superclass/interfaces
and see if they are in the repository descriptor...say grab the first
superclass/interface found that is in the descriptor.  I was just wondering if
anyone had any ideas how to make that code available on the main OJB release
line (even if it's a configurable item based on env property or something).  I
don't want to implement it just on my local copy for obvious reasons, but I also
want to minimize the impact my changes would make to the main product.  Can
anyone assist me as to how I would design this extension so as to 'play nice'
with the fantastic ongoing development the main contributers are doing?

As always, if you want any more information, don't hesitate to ask.

Cheers
Adam


------------------------------------------------------------
This email was sent from Netspace Webmail: http://www.netspace.net.au


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org