Shibboleth Developers

[Chad La Joie <>]

In v2, the context object that you used was at the bottom of a very
involved inheritance hierarchy.  In v3, there will be many context
objects in a tree structure.  Each service will take, as an argument, a
context object specific to that service and that object may take a
parent.  This allows the service-specific object to sit in a larger tree
of context objects.

For the velocity and scriptlet attribute definitions you don't need any
additional data, you'll just past the service specific context object to
velocity or the scriptlet.  In cases where you do need additional data
you'll navigate the context object tree.  So, if for example you were
looking for the user's session you would get the parent context and then
ask it for the SessionContext object.  Then from the SessionContext
object you'd get session-specific information.

In terms of documentation, there should not be any changes to the
configuration of the attribute definitions so all the v2 documentation
should be effectively the same for v3.

On 5/17/11 1:32 PM, Rod Widdowson wrote:
> This is another also "mostly dev only" question... 
> 
> Some of the attribute resolvers need a view on the wider world outside 
> attributes when they run (e.g.
> PrincipalAuthenticationMethodDefinition), or actually add such a view to 
> the context passed on to the "user" (Velocity & Scripted).
> 
> 
> Obviously the way that the plumbing is done in IdP3 is quite different, but 
> is the idea that something like
> getAttributeRequestContext() is going to be added to 
> net.shibboleth.idp.attribute.resolver.AttributeResolutionContext (or 
> possibly
> its parent class?).
> 
> If so:
> Shall I just leave the definitions that have the need for such a call until 
> the plumbing is done?  The Velocity and Scripted
> definitions can be added now of course - they will just have a more 
> restricted view of the world until the plubing is done.
> 
> If not:
> How will this plumbing be done?  I'm happy to wait and see, or even be told 
> to RTFCode...
> 
> On a related matter, just as it is easier to write tests before you write 
> the code (or at best shortly after) it is easiest to write
> documentation at the same time as the code.  Where the plugins are 
> identical of course new documentation is a no-op, but in cases
> where APIs have changed it would be nice to capture at least a framework 
> document now.  
> 
> So what is the plan for V3 documentation?  If things are not ready yet I'm 
> happy to just dump stuff in my personal space and move it
> over at a later date.
> 
> /Rod
> 
> 

-- 
Chad La Joie
http://itumi.biz
trusted identities, delivered