activationConditionRef problem
Rod Widdowson
rdw at steadingsoftware.com
Sun Jul 12 10:56:10 EDT 2015
> As an example, see if you can
> get a simple String bean built with a constructor set by name. I don't
think I
> managed it.
I walked the code. This appears to be a bug in the bytecode interpreter
(yes) inside Spring which doesn't find any parameters being looked at,
presumably because this is mostly a native class
> In this particular case it's probably ok to circumvent the ability to
specify "true" and "false" because
> hardwiring that into a condition like this probably doesn't serve much
purpose, but once in a while
> for debugging you might want to temporarily hardwire a condition to true
or false, so that's why
> I was a little hesitant to break that.
I don't think you'd be breaking it, just making it less accessible. After
all you can always say
<bean id="FalseBean" class="com.google.common.base.Predicates"
factory-method="alwaysFalse"/>
<bean id="ExampleOrgPredicate"
parent="shibboleth.Conditions.RelyingPartyId" c:pred-ref="FalseBean "/>
Or some such....
R
More information about the dev
mailing list