Shibboleth Developers

["Howard Gilbert" <>]

Summary: The current approach of separate Origin and Target distributions raises a problem for Java where there are classes that should be reused at both ends. Maintaining two copies of common source is not a good idea. An alternate package distributes a single library of all Java code with separate configurations for Origin and Target, or a combined deployment for testing, development, or where both functions are required.

 

 

In Java, the Origin and Target have the same program environment (the Servlet API), essentially the same configuration mechanisms, and a lot of common problems. This means that some modules and all the Exceptions can be shared.

 

Given that the current Origin is in CVS and was written by someone else, I have created a separate project. Copying a bunch of files from one project to another would produce a CVS mess, so for now the Target project depends on the Origin project and includes all the classes produced by the origin as part of its classpath.

 

This raises two questions about package naming and distribution.

 

In the current Java Origin, many classes that would be shared between the origin and target are in the edu.internet2.middleware.shibboleth.common package [which I will abbreviate "edu.i2.mid.shib..." from now on]. However, in the current code, "common" only means "shared by the HS and AA". A few Origin-only classes are in common. I can:

 

1) Leave this, and put corresponding target-only classes in the same package name.

2) Leave this, but put target-only classes in edu.i2.mid.shib.target. Then the "common" package would contain some truly common classes and some origin classes, but all target classes would have been segregated.

3) Move the origin-only classes to a new edu.i2.mid.shib.origin package. Then common would be common to all, origin would be origin-only, and target would be target-only.

 

This assumes that the other packages that are not explicitly AA, HS, or WAYF related (log, metadata, utils) can be left as is.

 

The second question relates to how everything gets zipped up. Java compiles to a directory tree of class files. The directory can be zipped up for distribution. A Java library zip file typically ends in the ".jar" extension. A Java Web application is zipped up and ends in a ".war" extension.

 

A web application directory tree (or ".war" image of the tree) has a subdirectory of appname/WEB-INF/lib in which it keeps .jar files of libraries on which it depends. For example, the current Java Origin distribution includes an opensaml.jar file in its WEB-INF/lib because we regard opensaml as a separate code base. However, all the class files belonging to the current Origin code are distributed in the WEB-INF/classes directory as individual class files. [Sanity check, they are zipped up into a single WAR file, but within that zip file they are individual files, while opensaml is a ZIP/JAR file inside the containing ZIP/WAR file.

 

This suggests several packaging methodologies:

 

1) The Origin is distributed as it currently is. The Target is distributed as its own WAR file. Common class files are duplicated in the two WAR's.

2) The common files shared by both Origin and Target are turned into a shibboleth-common.jar file (moving them from WEB-INF/classes to WEB-INF/lib). The two WAR files then include raw *.class files only for the origin-only and target-only files.

3) The Origin and Target are distributed as a single WAR file. This (presumably) shibboleth.war file would create everything (HS, AA, WAYF, SHIRE, and SHAR) in a single /shibboleth context of the Tomcat/AppServer. The user could configure which services he will really use.

4) The Origin and Target class files would be combined in a single shibboleth.jar file. Three WAR files could be created that would each include this jar file and create, based on the configuration of the WAR, either an Origin, Target, or Origin+Target combo.

 

The technical requirement is that the source projects be either combined or interdependent because there should be common code. The rest is aesthetic judgment and might just be voted on.