A better way to load a shib v2 service with no configuration ?

2 views
Skip to first unread message

Tom Zeller

unread,
Jan 2, 2012, 8:31:34 PM1/2/12
to d...@shibboleth.net
I need to define a shib v2 service (grouper as a provisioning target)
whose configuration is found on the classpath, so no configuration
resource is necessary. However, a configuration resource is required
to load the service. So, I created an "empty bean" xml config and java
class and pass them as the configuration resource.

Yeah, horrible. Is there a better way ?

Happy New Year,
TomZ

services.xml :

<!-- The grouper provisioning service target. -->
<Service id="grouper" xsi:type="psp-grouper-target:GrouperTarget" >
<!-- A <ConfigurationResource/> is required to instantiate the
<Service/>, so supply a do-nothing resource. -->
<ConfigurationResource
file="/edu/internet2/middleware/psp/util/empty-bean.xml"
xsi:type="resource:ClasspathResource" />
</Service>

emtpy-bean.xml :

<beans...>
<bean id="emptyBean"
class="edu.internet2.middleware.psp.util.EmptyBean" />
</beans>

EmptyBean.java :

package edu.internet2.middleware.psp.util;

/**
* Just an empty class.
*/
public class EmptyBean {

}
--
To unsubscribe from this list send an email to dev-uns...@shibboleth.net

Halm Reusser

unread,
Jan 3, 2012, 2:59:38 AM1/3/12
to Shib Dev
Hi Tom,

what do you mean by "a configuration resource is required
to load the service". If I take a look at the
shibboleth-2.0-services.xsd, the element ConfigurationResource of the
abstract service type is declared as 0-to-unbounded.

Does the code itself require it or does your "GrouperTarget" service
type overwrite the schema?

A minor improvement -but still not a nice solution- is to use
java.lang.Object as an empty bean class.

Happy New Year, too
-Halm

Tom Zeller

unread,
Jan 3, 2012, 10:04:36 AM1/3/12
to Shib Dev
> what do you mean by "a configuration resource is required
> to load the service". If I take a look at the
> shibboleth-2.0-services.xsd, the element ConfigurationResource of the
> abstract service type is declared as 0-to-unbounded.

Right, minOccurs="0" in the xsd, but in BaseService.java, if there are
no service configurations the context is not loaded :

protected void loadContext() throws ServiceException {
log.info("Loading new configuration for service {}", getId());

if(serviceConfigurations == null || serviceConfigurations.isEmpty()){
setInitialized(true);
return;
}

GenericApplicationContext newServiceContext = new
GenericApplicationContext(getApplicationContext());
...

> Does the code itself require it or does your "GrouperTarget" service
> type overwrite the schema?

No overwrite, the grouper target implements (extends) a Service.

> A minor improvement -but still not a nice solution- is to use
> java.lang.Object as an empty bean class.

Thanks.

Chad La Joie

unread,
Jan 4, 2012, 9:09:24 AM1/4/12
to Shib Dev
Tom, you can file an issue for this if you'd like. That's something I
could easily fix in the next patch (whenever that is).

Tom Zeller

unread,
Jan 4, 2012, 2:11:58 PM1/4/12
to Shib Dev
Thanks Chad.

https://issues.shibboleth.net/jira/browse/SIDP-533

No hurry.

On Wed, Jan 4, 2012 at 8:09 AM, Chad La Joie <laj...@shibboleth.net> wrote:
> Tom, you can file an issue for this if you'd like.  That's something I
> could easily fix in the next patch (whenever that is).
>
> On 1/3/12 10:04 AM, Tom Zeller wrote:
>>> what do you mean by "a configuration resource is required
>>> to load the service". If I take a look at the
>>> shibboleth-2.0-services.xsd, the element ConfigurationResource of the
>>> abstract service type is declared as 0-to-unbounded.
>>
>> Right, minOccurs="0" in the xsd, but in BaseService.java, if there are
>> no service configurations the context is not loaded :
>>
>>  protected void loadContext() throws ServiceException {
>>   log.info("Loading new configuration for service {}", getId());
>>
>>   if(serviceConfigurations == null || serviceConfigurations.isEmpty()){
>>    setInitialized(true);
>>    return;
>>   }
>>
>>  GenericApplicationContext newServiceContext = new
>> GenericApplicationContext(getApplicationContext());
>>  ...
>>
>>> Does the code itself require it or does your "GrouperTarget" service
>>> type overwrite the schema?
>>
>> No overwrite, the grouper target implements (extends) a Service.
>>
>>> A minor improvement -but still not a nice solution- is to use
>>> java.lang.Object as an empty bean class.

Reply all
Reply to author
Forward
0 new messages