Shibboleth Developers

["Howard Gilbert" <>]

> > /src/internet2/middleware/commons/log4j
> >
> > An optional request logging package also described separately and
> > distributed as its own jar file. But for now I will check it in here
> > so it doesn't get lost.
> 
> Could you say more about this?  How does this diverge from what we are
> already doing?

It doesn't effect "what we are doing" which is why it is a separate package.
I put a longer explanation of the feature on the Wiki

http://tp.its.yale.edu/shib/tiki-index.php?page=RequestLogger

Basically, it adds the ability, should you configure it, to return any
subset of the current log events to the Browser that makes a request. I
expect it will be tweaked a bit, but when done you can try to access a
resource and, if something goes wrong, get traces from the HS and Service
Provider (SHIRE) relating to the processing of your request. This may, if
configured, simplify the process of debugging problems in logic or
configuration reported when someone says "I can't get there from here." It
is entirely external to Shibboleth or any other application over which it
can be deployed, and operates as an extension to Log4J itself. However, if
you expect that this service is going to be available, you find yourself
adding log statements to the code differently because you are addressing a
different audience.

> > ShibResource.java - I propose a change to line 67, probable bug fix.
> > The existing code defaults to find resources from the JRE part of the
> > classpath. I change it to use the local ClassLoader and therefore to
> > find resources in the WEB-INF directory.
> 
> Why?

Well, all the "resources" that I am loading (configuration XML files, schema
XSD files, ...) are in the WEB-INF directory. To express this, you tell the
resource manager to use a ClassLoader associated with a Class that came from
WEB-INF. I think I had a problem getting this to work without changing it
(that is, I sure didn't propose the change just because I was reading
through the code and spotted it). However, from first principals of Java
ClassLoaders, you choose a Class that came from the same part of the
classpath and maybe even the same JAR or directory as the resource file you
are looking for.

There is a broader background discussion of ClassLoaders as a topic on the
Wiki

http://tp.its.yale.edu/shib/tiki-index.php?page=ClassLoader


> > /src/.../target
> >
> > A new package containing most of the new code.
> >
> >  Too numerous to mention here, and they are all new and don't change
> > or conflict with anything.
> 
> Could we not make this "target"?  "SP" or "serviceProvider"?

Sounds good. I stand ready with my trusty Eclipse Refactor-Rename. You can
rename an entire package in less time than it takes to discuss it.
Certainly, this should be done before checking it in the first time.
However, the use of capital letters anywhere in a package name is not
recommended, so how about "serviceprovider".

> > /webApplication
> >
> > The Ant script seems to require that some things (/lib JAR files, XSD
> > schemas) appear in both the source tree and the prototype application
> > directory. This should be fixed.
> 
> No problem reworking things here, if you want.  There is duplication
> because things need to exist for the webapp and the command line utils.

Short term I think I have no choice. I have to check in duplicate copies of
the JAR and XSD files. Longer term we may fix this.

The problem is that the "distribution" step builds a WAR file out of a
subdirectory of the project. The only little trick is that the Ant statement
that builds a WAR can take one external file and rename it to be the
WEB-INF/web.xml. Currently, the script builds the WAR over /webApplication
which is a checked in directory. 

    <property name="approot" value="${root}/webApplication/" />
    ...
    <war warfile="${dist}/${distname}.war" 
                webxml="${configroot}/mumblemumblemumble.xml" 
                basedir="${approot}" update="no" />

The alternative is to generate a new non-CVS subdirectory (typically /build
or /webapp) into which you copy the class files, resources, web pages, and
so on from /src, /lib, and webApplication. Then you build the WAR file with
a basedir= of that synthetic directory (which is excluded from CVS). That
way there is only one place for everything. However, I can't do this and
test it in the next few days, and that is the time frame for checking in. 

> > Ant Build
> >
> > This is probably the hardest part. There is one Ant build designed to
> > build a distributable target. I have made changes toward building a
> > testable image. This will be the last thing I check in and I may have
> > comments on it later.
> >
> 
> I'm definitely open to refining what we already have checked in.
> Suggestions?

Not at this time. I will check in something that works and does no harm. It
may take some trial and error before I am ready to propose a theme. Broadly
speaking there should be a distribution target and a test target. The
distribution target will generate production stuff, and the test target will
generate debug stuff.