Shibboleth Developers

[Scott Cantor <>]

> The Session object (found through the Request object) could 
> certainly cache attributes and contain a reference to an 
> object with a getAttribute() object. From the user's point of 
> view, there is no need for a handle to be visible. However, 
> if the SHIRE/SHAR is in another JVM, then under the covers 
> the classes implementing this application interface have to 
> communicate, just as the current code uses ONC RPC. To 
> communicate from Java, however, you need to use RMI, Corba 
> (but only with the addition of a J2EE EJB container), or Web 
> Services. If you use Web Services, you support other 
> languages and runtime environments.

Walter's suggestion was that some containers may support session migration,
in which serializable Java objects can be moved from one JVM to another by
some means internal to the container. This is used in load balanced
applications to avoid sticky sessions. The advantage to this approach is
that we get it "for free" without having to code much of anything. The
disadvantage is that it's probably container-specific whether it exists or
not.

> OK, then what gets put in the web.xml file parameters is the 
> URL of the external configuration file (which can be a local 
> file URL or an http: URL). What doesn't work is to expect the 
> configuration file to be in the current directory, because in 
> the typical Application Server there is no good way to 
> predict what the "current directory" will be when the server 
> starts up, and generally you won't have write/add privileges 
> to that directory even if you could figure it out.

We have a lot of experience with this. The origin is entirely in Java and we
know how to deal with configuration, though we've found that the properties
format is becoming too limited for us to use.

-- Scott