Shibboleth Developers

[Chad La Joie <>]

The issue is caused by a mismatch in models.  Spring does dependency 
injection and so its world view is that absolutely all dependencies 
should be bean properties.  This is makes it crystal clear what a given 
bean needs to run.

The alternative world view is generally known as the locator pattern. 
The idea is that what the bean gets is some handle to a registry 
somewhere in the system and when the bean needs something it looks up 
the required object in the registry (JNDI is the classical example of 
this in Servlet containers).  The problem with the locator pattern is 
that there is no way to inspect the APIs of an object and determine what 
exactly it depends on. It also create a tight coupling to the registry 
which can lead to issues in things like testing (not that we do a great 
job of that right now).

All logging frameworks that I know of use the locator pattern.  Because 
of this Spring has no way to know that a given bean needs the logging 
subsystem setup first, so you have to explicitly declare that.

On 6/2/10 10:45 PM, Tom Zeller wrote:
> Allright, thanks for the guidance. I was kind of surprised to see
> manual loading of "depends-on" as well, since I thought that was a
> spring built-in, but I'm not well versed.
>
> On Wed, Jun 2, 2010 at 3:19 PM, Chad La 
> Joie<>
>   wrote:
> > Ah, I see what you mean.  For now I'd recommend just pulling the line of
> > code:
> >
> > builder.addDependsOn("shibboleth.LogbackLogging");
> >
> > and I'll look in to whether there is a different way to ensure that the
> > logging service is started before the other beans.
> >
> > On 6/2/10 4:05 PM, Tom Zeller wrote:
> > > Without a "shibboleth.LogbackLogging" bean, an exception is thrown
> > > when loading the resolver :
> > >
> > >   org.springframework.beans.factory.NoSuchBeanDefinitionException: No
> > > bean named 'shibboleth.LogbackLogging' is defined
> > >
> > > To workaround, I declared
> > >
> > >   <bean id="shibboleth.LogbackLogging"
> > > class="edu.internet2.middleware.ldappc.spml.EmptyBean" />
> > >
> > > where EmptyBean is truly empty:
> > >
> > > public class EmptyBean { }
> > >
> > > and AbstractServiceBeanDefinitionParser is :
> > >
> > > public abstract class AbstractServiceBeanDefinitionParser ...
> > >   protected void doParse(...
> > >
> > >    builder.addDependsOn("shibboleth.LogbackLogging");
> > >    for (String dependency : XMLHelper
> > >       .getAttributeValueAsList(configElement.getAttributeNodeNS(null,
> > > "depends-on"))) {
> > >        builder.addDependsOn(dependency);
> > >     }
> > >
> > > Could an optional dependency on shibboleth.LogbackLogging be done in
> > > xml via depends-on, or is that unordered ? or a hassle ?
> > >
> > > On Wed, Jun 2, 2010 at 2:44 PM, Chad La 
> > > Joie<>
> > >     wrote:
> > > > I don't believe there is any hard dependency on the logging service. It's
> > > > only there to ensure that in Shib the logging service is started before
> > > > the
> > > > other beans.
> > > >
> > > > On 6/2/10 3:40 PM, Tom Zeller wrote:
> > > > > In shib-common 1.2.0, it looks like
> > > > > AbstractServiceBeanDefinitionParser now depends on the
> > > > > "shibboleth.LogbackLogging" bean. I'm reusing shib-common but not
> > > > > logback logging. Could that dependency be optional instead ? If not, I
> > > > > guess I can declare such a bean.
> > > > >
> > > > > Thanks,
> > > > > Tom
> > > >
> > > > --
> > > > Chad La Joie
> > > > http://itumi.biz
> > > > trusted identities, delivered
> >
> > --
> > Chad La Joie
> > http://itumi.biz
> > trusted identities, delivered

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