Skip to Content.
Sympa Menu

shibboleth-dev - More defined custom extensions mechanism

Subject: Shibboleth Developers

List archive

More defined custom extensions mechanism


Chronological Thread 
  • From: Chad La Joie <>
  • To:
  • Subject: More defined custom extensions mechanism
  • Date: Tue, 05 Jul 2005 10:18:25 -0400
  • Organization: UIS - Project Sentinel

There has been discussion off list about how to proceed with custom
extensions (name mappers, protocol handlers, etc) to Shibboleth, those
things that currently go in to the "custom" directory in the Shib IdP/SP
code base. Here is my proposition for a more formal and flexible way to
deal with these custom extension.

Each custom extension (or groups of extensions) would create a directory
within the "custom" directory. These extension directories would have
the following directory structure

<extension_directory>
etc/
lib/
src/
test/
build.properties

The "src" directory would contains your java sources for the extensions.
The "test" directory would contain any unit tests for them. The "etc"
directory would contain any number of directories that would simply be
copied in to the resulting extension jar, you would put any non-source
files that you wanted available on the class path in here (config files,
XML schemas, etc). The "lib" directory would contain any 3rd party
libraries you need for your stuff. Additional directories can be
included (documentation, config files that go somewhere else, etc) and
they'll just be ignored. The build.properties file would contain a
single property; the name of the resulting jar.

When the IdP or SP was built it would compile each extension in turn
(ensuring all the Shib and 3rd party extension classes/libs are on the
classpath) and place the resulting extension jar, and all 3rd party jars
(those in extension_directory/lib) into a lib directory in the "custom"
directory. Then, when the WARs were built for the IdP and SP, these jar
would be scooped up and put in the appropriate place. A by product of
this approach is a greatly simplified means of including custom
extension; compiling them in some fashion and just placing the resulting
jar(s) in the custom/lib directory.

Two issues with this approach. First, if different extensions use
different versions of the same 3rd party jar you'll get class conflicts.
This would be true whether the Shib build did any of this special stuff
or not. Second, extension authors are locked in to this source-tree
structure. For most extensions this is probably just fine, for more
complicated extensions this may not be good. I had discussed with a
couple people some idea for making this more flexible but ultimately we
decided that the additional complexity for everything BUT the extension
(and probably even for the extension) just wasn't worth it. So, for
these special extensions, they can create their own build process and
just place their jar(s) in the custom/lib directory.

Thoughts and comments?
--
Chad La Joie 315Q St. Mary's Hall
Project Sentinel 202.687.0124



Archive powered by MHonArc 2.6.16.

Top of Page