Grouper Developers Forum

[Dave Donnelly <>]

Signet uses a "database-within-a-database" to act as a
subject provider. One of the Signet utilities, SubjectFileLoader,
reads a flatfile and loads subject information into two tables
(subject and subjectattribute). These tables are then accessed
by a JDBCSourceAdapter to provide new Subjects whenever Signet
is creating proxies and/or assignments.

Neither of these tables are "official" Signet tables, but are,
I believe, legacy from a reference implementation of SubjectAPI
providing Subjects to Signet. I couldn't determine how to rewrite
SubjectFileLoader to conform to the new way SubjectAPI retrieves
Subjects because of the (new?) requirement for a single attribute
possibly having multiple values. Instead, I made the current JDBC
classes extend-able, sub-classed it, and overrode the methods that
affect Signet. The subclass (SignetJDBCSourceAdapter) is contained
in the Signet project and does not affect the Subject project.

Signet's persistence layer (the "official" tables) does store Subject
information, including a Subject's "attributes of interest" (those
attributes Signet's configuration file has identified). However,
subjects are persisted as SignetSubjects, not JDBCSubjects or Subjects,
and attributes are stored as SignetSubjectAttributes.

I hope I haven't overstepped any boundaries, broken protocol, or
ruffled feathers by making these changes without consulting the
SubjectAPI developers first. As I said, the changes were minor
and should not affect any dependent code.

--Dave



Tom Barton wrote:
> Dave Donnelly wrote:
> > Hi all,
> >
> > I've made some minor changes to JDBCSourceAdapter and JDBCSubject
> > to allow Signet to subclass JDBCSourceAdapter. The way the
> > source adapter loads subject attributes was incompatible with
> > Signet's storage of same.
>
> I'm curious - is Signet storing subject attributes (and why, if so), 
> and even if so, how does that conflict with how Subject objects are 
> created?
>
> Tom